It is helpful for a data processor programmer to be able to observe the flow of software and its effect on internal registers, in order to diagnose and correct problems in the software. Traditionally, devices such as in-circuit emulators have been used. The in-circuit emulator has a pod which can be plugged in to a microprocessor socket. The in-circuit emulator acts like the microprocessor, but has the capability to perform single steps through the software and display the contents of the microprocessor's internal registers at each step. Older in-circuit emulators mimicked the performance of the microprocessor by using discrete circuitry whose operation duplicated that of the microprocessor, but which could be freely accessed in order to reveal the contents of the registers. In order to simplify in-circuit emulation, microprocessors started to be designed with features which would allow the microprocessor itself to be used in and to support emulation.
For example, the 68000 microprocessor available from Motorola, Inc. included a trace mode which single-stepped the microprocessor through the software, allowing the contents of internal registers to be viewed after each instruction. The 96002 digital signal processor (DSP), also available from Motorola, Inc., further enhanced emulation support by including an on-chip emulation circuit which allows for setting programmable breakpoints. These breakpoints would trigger on the occurrence of a particular program address.
Microprocessors themselves are also becoming more complex. Earlier microprocessors merely included a central processing unit (CPU), used a von Neumann architecture (contiguous program and data address spaces), and only had registers on-chip which were part of the programmer's model. More recently, microprocessors have included general purpose on-chip memory, both volatile and non-volatile. Recent microprocessors have also used a Harvard architecture (separate program and data address spaces), sometimes multiplexing accesses to each space. In addition, microprocessors have become more specialized. Commercially-available microprocessors now include conventional complex instruction set computer (CISC) microprocessors, reduced instruction set computer (RISC) microprocessors, microcomputer (embedded) processors, scalar processors, floating point processors, specialized coprocessors, and DSPs. The evolution of the microprocessor in these directions creates new difficulties for providing needed diagnostic capabilities.
The use of microprocessors in embedded control applications where information is processed in real-time, such as in a DSP, does not permit the microprocessor to be halted and interrogated as in other types of applications. Information on how or where a program is executing must be obtained in such a manner that the microprocessor cannot be interrupted. In the prior art of evaluating program flow, a microprocessor is either interrupted so that information is extracted, or the microprocessor is put in such a mode that the internal bus operation appears on the external bus at certain intervals. Such real-time applications include disk controllers and anti-lock brake systems, for example, where any interruption of the microprocessor's functions can cause the system to break or "crash".
This interruption is not allowable when a user tries to evaluate a program's flow for specific problems in low power applications where the external bus is either not accessible or is not to be activated. The use of external bus activity may cause simultaneous switching noise problems especially at low voltages. Also, stealing microprocessor clock cycles to extract this information may not be permissible in some applications. What is needed is a microprocessor which allows the user to evaluate program flow while the microprocessor runs in real-time, without sacrificing clock cycles.